@mediadatafusion/pi-workflow-suite 0.0.10 → 0.0.13
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +73 -0
- package/README.md +146 -20
- package/VERSION +1 -1
- package/agents/codebase-research.md +7 -5
- package/agents/general-worker.md +9 -7
- package/agents/implementation-planning.md +5 -3
- package/agents/quality-validation.md +9 -8
- package/agents/workflow-orchestrator.md +9 -7
- package/config/prompts/execute-approved-plan.md +12 -2
- package/config/prompts/mission-final-validation.md +38 -5
- package/config/prompts/mission-plan.md +17 -1
- package/config/prompts/mission-repair.md +16 -2
- package/config/prompts/mission-review-prompt.md +55 -0
- package/config/prompts/mission-run.md +18 -5
- package/config/prompts/validate-approved-plan.md +57 -3
- package/config/prompts/workflow-plan-prompt.md +11 -1
- package/config/prompts/workflow-repair.md +18 -2
- package/config/prompts/workflow-reviewer-prompt.md +60 -0
- package/config/prompts/workflow-summary.md +1 -4
- package/config/workflow-settings.example.json +13 -11
- package/extensions/subagent/index.ts +41 -18
- package/extensions/subagent/repolock-guard.ts +224 -4
- package/extensions/subagent/runner.ts +136 -12
- package/extensions/workflow-model-router.ts +152 -55
- package/extensions/workflow-modes.ts +4784 -1087
- package/extensions/workflow-settings-capabilities.ts +10 -0
- package/extensions/workflow-state.ts +139 -15
- package/extensions/workflow-subagent-policy.ts +13 -1
- package/extensions/workflow-summary.ts +8 -19
- package/extensions/workflow-tool-guard.ts +420 -39
- package/extensions/workflow-validation-classifier.ts +46 -4
- package/extensions/workflow-web-tools.ts +361 -1
- package/package.json +9 -5
- package/scripts/audit-live.sh +1 -1
- package/scripts/build-package-export.mjs +8 -13
- package/scripts/check-clean-release-tree.sh +3 -2
- package/scripts/check-package-media.mjs +78 -0
- package/scripts/install-to-live.sh +2 -0
- package/scripts/package-media-config.mjs +28 -0
- package/scripts/prepare-package-readme.mjs +19 -18
- package/scripts/quarantine-live-junk.sh +1 -1
- package/scripts/verify-live.sh +9 -1
- package/skills/implementation-planning/SKILL.md +1 -1
- package/skills/safe-execution/SKILL.md +1 -1
- package/skills/validation-review/SKILL.md +1 -1
package/CHANGELOG.md
CHANGED
|
@@ -2,6 +2,79 @@
|
|
|
2
2
|
|
|
3
3
|
All notable public releases will be documented in this file.
|
|
4
4
|
|
|
5
|
+
## [0.0.13] - 2026-06-08
|
|
6
|
+
|
|
7
|
+
### Changed
|
|
8
|
+
|
|
9
|
+
- Prepared the small runtime package to use the refreshed `0.0.12` npm-hosted package media while keeping promotional media assets out of the install payload.
|
|
10
|
+
|
|
11
|
+
## [0.0.12] - 2026-06-07
|
|
12
|
+
|
|
13
|
+
### Added
|
|
14
|
+
|
|
15
|
+
- Added `workflow_stop_server` for platform-aware cleanup of temporary dev and static servers after validation checks.
|
|
16
|
+
- Added independent text-style controls for workflow widgets and startup visuals.
|
|
17
|
+
- Added Mission saved-history retention with a dedicated Mission History settings surface.
|
|
18
|
+
- Added clearer sub-agent worker policy controls for Standard, Plan, and Mission workflow phases.
|
|
19
|
+
|
|
20
|
+
### Changed
|
|
21
|
+
|
|
22
|
+
- Refined Standard, Plan, and Mission widgets with clearer top/bottom status, progress, model route, runtime, repair, and validation context.
|
|
23
|
+
- Improved Standard Mode To Do, clarification, and status behavior for direct active work.
|
|
24
|
+
- Improved sub-agent orchestration language and behavior around planning, execution preparation, review, validation, and repair support.
|
|
25
|
+
- Clarified token and runtime tradeoffs for worker-backed workflows and deeper sub-agent policies.
|
|
26
|
+
- Clarified presets as workflow behavior profiles that do not change model, provider, auth, session, or shared compaction settings.
|
|
27
|
+
- Rebalanced Plan and Mission reviewer routing so safe, executable work preserves reviewer findings as notes unless a true blocker requires repair.
|
|
28
|
+
|
|
29
|
+
### Hardened
|
|
30
|
+
|
|
31
|
+
- Hardened Plan handoffs across reviewer, executor, validator, repair, and re-review phases.
|
|
32
|
+
- Hardened Mission recovery so provider, API, rate-limit, or no-output interruptions preserve repair evidence, validation reports, retry counts, and next actions.
|
|
33
|
+
- Hardened forced sub-agent policies and worker lifecycle cleanup.
|
|
34
|
+
- Hardened parent-owned workflow boundaries so background worker evidence supports the active phase without replacing the main workflow controller.
|
|
35
|
+
- Hardened Repo Lock and tool guards around protected files, temporary evidence, skill reads, screenshot paths, and destructive commands.
|
|
36
|
+
- Hardened validation evidence classification for browser, runtime, endpoint, and localStorage evidence gaps.
|
|
37
|
+
|
|
38
|
+
### Fixed
|
|
39
|
+
|
|
40
|
+
- Fixed Standard clarification answer routing and menu handoffs.
|
|
41
|
+
- Fixed Standard status display so user-facing states are shown instead of internal phase labels.
|
|
42
|
+
- Fixed Plan reviewer PASS/NOTES handoff recovery and progress widget drift.
|
|
43
|
+
- Fixed Mission validation interruptions that could obscure completed repair or PASS evidence.
|
|
44
|
+
- Fixed preset operations that could affect user-owned model/provider or compaction state.
|
|
45
|
+
- Fixed reviewer repair recovery paths so reviewer blockers are not confused with validation repair.
|
|
46
|
+
|
|
47
|
+
## [0.0.11] - 2026-05-30
|
|
48
|
+
|
|
49
|
+
### Added
|
|
50
|
+
|
|
51
|
+
- `workflow_browser_check` tool — headless browser verification for validator mode with interactive actions (click, type, read, reload, screenshot, evaluate). Uses Puppeteer from the Pi runtime so validators can verify web app behavior regardless of the target project's dependencies.
|
|
52
|
+
- Token budget controls (`maxTokens`, `maxRuntimeHours`) for Plan, Mission, and Standard modes.
|
|
53
|
+
- Structured validation boolean fields (`concreteRepairableIssue`, `manualVerificationRequired`, `evidenceGap`) on workflow and mission state for infallible classification.
|
|
54
|
+
- `/plan complete` command for explicit Plan Mode completion.
|
|
55
|
+
- Mission reviewer and workflow reviewer prompt templates.
|
|
56
|
+
|
|
57
|
+
### Hardened
|
|
58
|
+
|
|
59
|
+
- **Validation pipeline**: PARTIAL PASS with no concrete code defects now completes the workflow. Classifier reordered so concrete fixes route to repair over evidence gaps. Expanded automatable-evidence-gap detection. Mission validation manual-only outcomes advance milestones; final-validation manual-only outcomes complete the mission.
|
|
60
|
+
- **Reviewer and repair**: Mission reviewer auto-repair uses centralized default-enabled configuration matching Plan Mode. Built-in mission defaults aligned (reviewer auto-repair enabled, retry mode `safe_only`, max retries 2). Consistent retry gating across both modes.
|
|
61
|
+
- **Tool guard and Repo Lock**: Safe-command recognition expanded across package managers and ecosystems (pnpm, yarn, bun, npx serve, python3, curl localhost, ps, pgrep, sleep). Shell preamble handling (`stripSafePreamble`) for `set -e` and `export` patterns. `/tmp/` and `/dev/` paths exempted from Repo Lock blocking. Reduced false-positive destructive-command blocks.
|
|
62
|
+
- **Prompts and agents**: Unified inline-diagram guidance across all prompts, agents, and skills. Web app verification procedures with structured evidence output requirements in validator prompts. Sub-agent write-ownership clarified in mission run prompt. Agent Mermaid guidance updated for raw blocks since sub-agents lack `workflow_diagram`.
|
|
63
|
+
- **Runtime accounting**: Wall-clock age uses terminal timestamp when workflow is stopped. Active-runtime tracking preserved for workflows that began before the current session.
|
|
64
|
+
- **Plan Mode progress tracking**: Plan execution step progress now reliably tracks across all steps. The `workflow_progress` tool is guaranteed on the agent's active tool surface every turn. The progress guard enforces step activation before file writes while allowing sub-agents to run freely for research and preparation. Multi-step prompt guidance with inline step status display keeps the agent aligned with the approved plan from first step through final validation.
|
|
65
|
+
|
|
66
|
+
### Fixed
|
|
67
|
+
|
|
68
|
+
- Plan execution sub-agents no longer deadlock against the step progress guard when forced sub-agent policies are active.
|
|
69
|
+
- Plan Mode step progress widget consistently updates across multi-step execution instead of staying stuck on step 1.
|
|
70
|
+
|
|
71
|
+
### Updated
|
|
72
|
+
|
|
73
|
+
- Validators can write temporary evidence-gathering scripts (was read-only).
|
|
74
|
+
- Mission `maxRuntimeHours` default 8→13.
|
|
75
|
+
- All 4 built-in presets updated with `planShowProgressBar`.
|
|
76
|
+
- Internal architecture documentation expanded with model routing, settings merge chain, and preset bundle architecture.
|
|
77
|
+
|
|
5
78
|
## [0.0.10] - 2026-05-25
|
|
6
79
|
|
|
7
80
|
### Changed
|
package/README.md
CHANGED
|
@@ -1,10 +1,10 @@
|
|
|
1
1
|
# Pi Workflow Suite
|
|
2
2
|
|
|
3
|
-
|
|
4
4
|
|
|
5
|
-
[](#installation) [](#quick-start) [](#core-commands) [](#settings-reference)
|
|
6
6
|
|
|
7
|
-
**Workflow Suite Version:** `v0.0.
|
|
7
|
+
**Workflow Suite Version:** `v0.0.13`
|
|
8
8
|
|
|
9
9
|
## Overview
|
|
10
10
|
|
|
@@ -16,23 +16,23 @@ Pi itself is intentionally minimal and extensible. Pi Workflow Suite layers an o
|
|
|
16
16
|
|
|
17
17
|
See Pi Workflow Suite in action: structured workflow modes, settings, runtime status, and guided execution inside Pi.
|
|
18
18
|
|
|
19
|
-
[](https://cdn.jsdelivr.net/npm/@mediadatafusion/pi-workflow-suite@0.0.12/docs/assets/pi-workflow-suite-demo.mp4)
|
|
20
20
|
|
|
21
21
|
## Screenshots
|
|
22
22
|
|
|
23
|
-
|
|
24
24
|
|
|
25
|
-
|
|
26
26
|
|
|
27
|
-
|
|
28
28
|
|
|
29
|
-
|
|
30
30
|
|
|
31
|
-
|
|
32
32
|
|
|
33
|
-
|
|
34
34
|
|
|
35
|
-
|
|
36
36
|
|
|
37
37
|
## Contents
|
|
38
38
|
|
|
@@ -55,6 +55,7 @@ See Pi Workflow Suite in action: structured workflow modes, settings, runtime st
|
|
|
55
55
|
- [Compaction Support](#compaction-support)
|
|
56
56
|
- [Diagram Support](#diagram-support)
|
|
57
57
|
- [Web Access](#web-access)
|
|
58
|
+
- [Browser Verification](#browser-verification)
|
|
58
59
|
- [Repository Lock](#repository-lock)
|
|
59
60
|
- [Plan History](#plan-history)
|
|
60
61
|
- [Mission Progress, Checkpoints, And Runtime Tracking](#mission-progress-checkpoints-and-runtime-tracking)
|
|
@@ -115,9 +116,10 @@ Pi Workflow Suite turns Pi into a guided workflow environment:
|
|
|
115
116
|
| Mission Mode | Long-running milestone workflows with approval, checkpoints, Mission-specific model overrides, validation gates, repair/retry, pause/resume, final-validation controls, and continuity tracking. |
|
|
116
117
|
| Themes And Startup UI | Workflow Suite themes, startup visual cards, startup logo modes, custom terminal logo text, custom brand cards, footer/status styling, widgets, and optional input border styling. |
|
|
117
118
|
| Interactive Diagrams | `workflow_diagram` Mermaid support with terminal preview, SVG-first clickable artifacts, PNG/runtime rendering support, dark-mode-friendly styling, and runtime artifact storage. |
|
|
118
|
-
| Web Research | First-party `workflow_web_search` and `
|
|
119
|
+
| Web Research & Browser Verification | First-party `workflow_web_search`, `workflow_web_fetch`, and `workflow_browser_check` tools. Search and fetch for public web evidence with source URLs, blocked local/private/internal hosts, and time/size limits. Headless browser verification for runtime web app validation with interactive UI actions (click, type, read, screenshot, evaluate). |
|
|
119
120
|
| Repo Lock | Project-scoped Global Safety control that constrains normal file tools, bash path checks, and sub-agents to the active repository, with protected configuration paths and clear non-sandbox caveats. |
|
|
120
121
|
| Compaction | Pi default, custom model, or disabled Workflow Suite compaction so context summarization can use its own provider/model, proactive threshold checks, idle-boundary execution, custom token tuning, adaptive fitting, status reporting, and safe fallback. |
|
|
122
|
+
| Token Budgets | Optional per-mode token and runtime caps (`maxTokens`, `maxRuntimeHours`) for Plan, Mission, and Standard Mode. Off by default (unlimited). When enabled, Workflow Suite tracks cumulative usage and blocks further agent turns when the budget is exceeded. |
|
|
121
123
|
| Workflow Roles | Planner, Executor, Reviewer, Validator, Mission, and compaction responsibilities are separated by phase so each job has clear boundaries and can be matched to the right model. |
|
|
122
124
|
| Model Selection | Configure which provider/model and thinking level powers each workflow role, with shared defaults plus Standard-specific and Mission-specific overrides for simpler or higher-rigor setups. |
|
|
123
125
|
| Presets | Built-in and custom workflow profiles with selector commands and Ctrl+Shift+U cycling while active modes are running. |
|
|
@@ -134,13 +136,16 @@ Pi Workflow Suite turns Pi into a guided workflow environment:
|
|
|
134
136
|
- Mission Mode through `/mission`, `/m`, and `Ctrl+Shift+M` for durable milestone workflows.
|
|
135
137
|
- Configurable clarification in Standard Mode, plus dynamic clarification in Plan Mode and Mission Mode.
|
|
136
138
|
- Review, execution, validation, repair, retry, checkpoint, and final-validation controls where the selected mode supports them.
|
|
137
|
-
- Plan history, mission checkpoint history, Standard runtime tracking, Mission runtime tracking
|
|
139
|
+
- Plan history, mission checkpoint history, Standard runtime tracking, and Mission runtime tracking.
|
|
140
|
+
- Mode-aware progress widgets: Plan step tracking with step-by-step progress and validation gates, Mission milestone tracking with checkpoint history, and Standard Mode dynamic To Do progress.
|
|
141
|
+
- Configurable widget and startup visual text styling, with clearer top/bottom workflow status for active, ready, progress, validation, repair, and runtime states.
|
|
138
142
|
- Workflow settings UI for Standard Mode, Plan Mode, Mission Mode, model selection, sub-agents, compaction, widgets, themes, startup visuals, and safety.
|
|
139
143
|
- Workflow themes with a `none` option, startup visual cards, startup logo modes, custom terminal logo text, custom brand cards, and optional themed input borders.
|
|
140
|
-
- Integrated `workflow_web_search` and `
|
|
144
|
+
- Integrated `workflow_web_search`, `workflow_web_fetch`, and `workflow_browser_check` tools for current public evidence, source-backed URL reading, and headless browser verification of web app runtime behavior.
|
|
141
145
|
- Interactive `workflow_diagram` Mermaid rendering with terminal preview, clickable SVG artifacts, and PNG/runtime rendering support.
|
|
142
146
|
- Repo Lock for project-scoped path safety around repository work, protected project configuration, and sub-agent inheritance.
|
|
143
147
|
- Role-aware model selection so planning, execution, review, validation, Mission work, and compaction can each use the provider/model and thinking level that fits the job.
|
|
148
|
+
- Optional per-mode token and runtime budgets (`maxTokens`, `maxRuntimeHours`) to cap usage in Plan, Mission, and Standard Mode. Off by default; enable when you need predictable cost or time limits.
|
|
144
149
|
- Sub-agent usage policies for planning, execution, repair, review, and validation, with explicit documentation that these are orchestration settings, not a universal permission manager.
|
|
145
150
|
- Safe install, backup, audit, quarantine, verification, and package validation scripts.
|
|
146
151
|
|
|
@@ -433,6 +438,82 @@ The grouped settings menus expose shared role selection, Standard-specific model
|
|
|
433
438
|
|
|
434
439
|
Shared model selection is available through `/workflow settings Shared Models`. Standard-specific and mission-specific model selection is available through their mode settings menus.
|
|
435
440
|
|
|
441
|
+
## Efficiency Guidance
|
|
442
|
+
|
|
443
|
+
Workflow Suite gives you independent control over workflow rigor and model cost. This section explains which settings affect token usage and how to tune them.
|
|
444
|
+
|
|
445
|
+
### Thinking Levels
|
|
446
|
+
|
|
447
|
+
Six thinking levels control how much reasoning the model applies per inference:
|
|
448
|
+
|
|
449
|
+
```text
|
|
450
|
+
off < minimal < low < medium < high < xhigh
|
|
451
|
+
```
|
|
452
|
+
|
|
453
|
+
Higher levels use more tokens. Recommendations by role:
|
|
454
|
+
|
|
455
|
+
| Role | Guidance |
|
|
456
|
+
|------|----------|
|
|
457
|
+
| Planner | Higher thinking is often worth the cost — the plan defines scope, assumptions, risk, and validation strategy. |
|
|
458
|
+
| Reviewer | Higher thinking helps catch missing requirements, unsafe steps, or weak plans before execution begins. |
|
|
459
|
+
| Validator | Higher thinking reduces shared blind spots with the executor. An independent validator with a different model is more valuable than maxing thinking on the same model. |
|
|
460
|
+
| Executor | Medium-high is usually sufficient. Execution is about precise tool use and instruction following, not open-ended analysis. |
|
|
461
|
+
| Compaction | Summarization is mechanical. If using a custom compaction model, a lower thinking level or a cheaper model is often appropriate. |
|
|
462
|
+
|
|
463
|
+
Note: Pi may clamp thinking levels for model/provider combinations that do not support the requested level. This is Pi runtime behavior, not a Workflow Suite setting.
|
|
464
|
+
|
|
465
|
+
### Token Budgets
|
|
466
|
+
|
|
467
|
+
Each mode supports an optional configurable token budget:
|
|
468
|
+
|
|
469
|
+
- `planning.maxTokens` — caps estimated token usage for a Plan Mode workflow.
|
|
470
|
+
- `missions.maxTokens` — caps estimated token usage for a Mission Mode workflow.
|
|
471
|
+
- `standard.maxTokens` — caps estimated token usage for a Standard Mode session.
|
|
472
|
+
|
|
473
|
+
Default is `0` (unlimited). When set to a positive value, Workflow Suite tracks cumulative usage and blocks further agent turns when the budget is exceeded. Set budgets with headroom — the tracker uses context window size as a proxy since Pi does not expose cumulative token counts.
|
|
474
|
+
|
|
475
|
+
Configure through `/workflow settings Plan Mode`, `/workflow settings Mission Mode`, or `/workflow settings Standard Mode`.
|
|
476
|
+
|
|
477
|
+
### Sub-Agent Policy And Token Cost
|
|
478
|
+
|
|
479
|
+
Sub-agent policies control how many parallel workers are requested per phase:
|
|
480
|
+
|
|
481
|
+
```text
|
|
482
|
+
off < auto < deep < maximum < forced
|
|
483
|
+
```
|
|
484
|
+
|
|
485
|
+
Each worker has its own context window, so more workers multiply token spend. The built-in presets scale worker counts from 1 (simple) to 4 (maximum). For cost-sensitive work:
|
|
486
|
+
|
|
487
|
+
- Use `auto` to let the model decide when workers are worth the cost.
|
|
488
|
+
- Lower worker counts in `deep`/`maximum`/`forced` policies.
|
|
489
|
+
- Disable phases that are not needed for the current task.
|
|
490
|
+
|
|
491
|
+
Worker-backed phases can improve coverage and speed, but each worker uses its own context window, so deeper sub-agent policies should be balanced against token budget and runtime goals.
|
|
492
|
+
|
|
493
|
+
Sub-agent settings are configured through `/workflow settings Shared Sub-agents`, with per-mode overrides in Standard Mode and Mission Mode settings.
|
|
494
|
+
|
|
495
|
+
### Settings That Affect Token Usage
|
|
496
|
+
|
|
497
|
+
| Setting | Impact |
|
|
498
|
+
|---------|--------|
|
|
499
|
+
| Thinking levels (per role) | Directly controls tokens per inference for each workflow phase. |
|
|
500
|
+
| Sub-agent policies and worker counts | More workers = more parallel context windows = higher total spend. |
|
|
501
|
+
| `maxClarificationQuestions` | Higher counts mean more clarification turns before work begins. |
|
|
502
|
+
| `planning.depth` | `deep`/`maximum` prompt for more sub-agent research before planning. |
|
|
503
|
+
| `validationRetryMode` | `aggressive_within_scope` can trigger more repair cycles. |
|
|
504
|
+
| `finalValidationEnabled` | Adds a whole-mission validation pass after all milestones complete. |
|
|
505
|
+
| `maxTokens` (per mode) | Optional budget cap; blocks further turns when exceeded. |
|
|
506
|
+
|
|
507
|
+
### Presets And Models Are Independent
|
|
508
|
+
|
|
509
|
+
Presets control workflow behavior (approval gates, review/validation automation, sub-agent policy, repair retries). Models control which provider/model powers each role. They are intentionally separate:
|
|
510
|
+
|
|
511
|
+
- Cycling presets does not change model selections.
|
|
512
|
+
- Changing models does not affect preset behavior.
|
|
513
|
+
- You can run `deep` preset with small models or `simple` preset with large models.
|
|
514
|
+
|
|
515
|
+
This separation lets you tune workflow rigor and model cost independently.
|
|
516
|
+
|
|
436
517
|
## Workflow Settings UI
|
|
437
518
|
|
|
438
519
|
The settings UI is the main control surface for workflow behavior. Canonical command vocabulary is: `list` prints information to the screen, `configure` opens an interactive configuration menu, `set` directly changes a setting, and workflow actions use direct verbs such as plan, run, validate, answer, approve, or cancel.
|
|
@@ -577,7 +658,9 @@ Workflow Theme
|
|
|
577
658
|
How the pieces fit together:
|
|
578
659
|
|
|
579
660
|
- **Theme** changes Workflow Suite colors for widgets, footer/status text, startup visuals, and optional input border styling.
|
|
661
|
+
- **Widget Text Style** controls the text treatment used by active workflow widgets.
|
|
580
662
|
- **Startup Visual** chooses the startup card layout: `none`, `minimal`, `workflow_duo`, `mission_control`, `diagnostic_center`, `data_stream`, `neural_grid`, or `custom_brand`.
|
|
663
|
+
- **Startup Text Style** controls startup visual text independently from active workflow widgets.
|
|
581
664
|
- **Startup Logo** chooses what appears above the startup card: `none`, `pi`, or `custom`.
|
|
582
665
|
- **Custom Logo** uses short terminal text from `logo-text`; it is not an image, SVG, or file path.
|
|
583
666
|
- **Custom Brand** is for the `custom_brand` startup card. `brand text` sets the card text and `brand base` selects the card template.
|
|
@@ -618,6 +701,8 @@ Bundled skills include:
|
|
|
618
701
|
|
|
619
702
|
Sub-agent settings are workflow orchestration policy, not a universal permissions UI. They influence when Pi Workflow Suite asks to use sub-agents during planning, execution, repair, review, and validation, and how aggressively it should do so. Standard Mode can use its own phase-specific overrides while inheriting shared sub-agent settings by default. Built-in presets intentionally force sub-agent use so independent workers become the normal path, especially for execution.
|
|
620
703
|
|
|
704
|
+
Sub-agent policies let users choose how much background assistance each workflow phase should request. Lighter policies keep workflows simpler and cheaper; deeper or forced policies can add independent research, implementation preparation, challenge review, validation evidence, and repair planning before the parent workflow proceeds.
|
|
705
|
+
|
|
621
706
|
They include:
|
|
622
707
|
|
|
623
708
|
- phase policies: `off`, `auto`, `deep`, `maximum`, `forced`,
|
|
@@ -626,6 +711,16 @@ They include:
|
|
|
626
711
|
- global and project agent discovery,
|
|
627
712
|
- parallelism preferences for workflow phases.
|
|
628
713
|
|
|
714
|
+
Sub-agent orchestration varies by mode and phase:
|
|
715
|
+
|
|
716
|
+
| Mode | Planning | Execution | Validation |
|
|
717
|
+
|---|---|---|---|
|
|
718
|
+
| Plan | Research, codebase inspection, risk discovery | Scoped implementation help, file inspection, patch planning | Evidence gathering, regression search |
|
|
719
|
+
| Mission | Milestone planning research, dependency analysis | Per-milestone implementation support | Per-milestone and final validation evidence |
|
|
720
|
+
| Standard | Task analysis, approach research | File inspection, implementation assistance | Quality review, regression checking |
|
|
721
|
+
|
|
722
|
+
Forced sub-agent policies (available in all three modes) require a minimum number of successful workers before the agent can proceed to file writes, ensuring independent analysis and preparation are applied before implementation.
|
|
723
|
+
|
|
629
724
|
Important limits:
|
|
630
725
|
|
|
631
726
|
- Pi Workflow Suite does **not** provide a UI for editing arbitrary sub-agent tool permissions.
|
|
@@ -753,7 +848,7 @@ workflow_web_search
|
|
|
753
848
|
workflow_web_fetch
|
|
754
849
|
```
|
|
755
850
|
|
|
756
|
-
|
|
851
|
+
`workflow_web_search` uses DuckDuckGo HTML search for current external evidence and source URLs. `workflow_web_fetch` reads specific public HTTP(S) URLs and extracts text for source-backed evidence. Web content from search and fetch is treated as untrusted evidence, not as instructions.
|
|
757
852
|
|
|
758
853
|
Safety boundaries:
|
|
759
854
|
|
|
@@ -763,7 +858,27 @@ Safety boundaries:
|
|
|
763
858
|
- visible answers should cite source URLs when web evidence is used,
|
|
764
859
|
- sub-agent workers may not have the parent Workflow Suite web tools, so parent modes should perform required web research and pass findings into handoffs when needed.
|
|
765
860
|
|
|
766
|
-
Web access is Pi extension behavior, not a guarantee that every model, sub-agent, network, or runtime environment can reach the public web. If
|
|
861
|
+
Web access is Pi extension behavior, not a guarantee that every model, sub-agent, network, or runtime environment can reach the public web. If a web tool fails, Workflow Suite reports the failure and continues from available context.
|
|
862
|
+
|
|
863
|
+
## Browser Verification
|
|
864
|
+
|
|
865
|
+
Workflow Suite registers a `workflow_browser_check` tool for headless browser verification:
|
|
866
|
+
|
|
867
|
+
```text
|
|
868
|
+
workflow_browser_check
|
|
869
|
+
```
|
|
870
|
+
|
|
871
|
+
This tool launches a headless Chromium browser via Puppeteer from the Pi runtime and works regardless of the target project's dependencies. It is available in all modes by default when the runtime supports it.
|
|
872
|
+
|
|
873
|
+
**Interactive actions:** The tool supports click, type, read, wait, reload, screenshot, and evaluate actions. Validators can exercise UI flows end-to-end — clicking through pages, typing into forms, reading updated text, and capturing screenshots — rather than only observing static page state. Screenshots are saved to `/tmp/validator_screenshot.png`.
|
|
874
|
+
|
|
875
|
+
**Validator workflows:** Validators use `workflow_browser_check` to verify web app runtime behavior: console errors, page errors, DOM element counts, localStorage state, and interactive UI correctness. This provides automatable browser-level evidence for validation reports without requiring manual human verification.
|
|
876
|
+
|
|
877
|
+
**Executor and planner use:** Executors and planners can also use the tool to verify their own work during implementation — starting a dev server, running browser checks, and confirming behavior before handing off to validation.
|
|
878
|
+
|
|
879
|
+
**Server cleanup:** Validator prompts can pair browser checks with `workflow_stop_server` so temporary dev or static servers can be cleaned up after runtime validation.
|
|
880
|
+
|
|
881
|
+
**Graceful fallback:** If Puppeteer is not available in the Pi runtime, the tool reports the error and the workflow continues from available context. Browser verification is an enhancement, not a hard dependency.
|
|
767
882
|
|
|
768
883
|
## Repository Lock
|
|
769
884
|
|
|
@@ -781,6 +896,8 @@ Repo Lock does not grant normal agent tools access to the live Pi runtime under
|
|
|
781
896
|
|
|
782
897
|
Repo Lock helps prevent accidental cross-repository work. It is not an operating-system sandbox, a complete shell parser, or a guarantee that every possible child process is contained. Review commands before running them, especially commands that invoke other tools or scripts.
|
|
783
898
|
|
|
899
|
+
Repo Lock is enabled by default in the Standard, Deep, and Maximum built-in presets. If your workflow requires cross-repository access, disable it through `/workflow settings Global Safety` or by setting `safety.repoLockEnabled` to `false`.
|
|
900
|
+
|
|
784
901
|
## Plan History
|
|
785
902
|
|
|
786
903
|
Plan history can persist workflow plans under Pi runtime state. Saved plans include:
|
|
@@ -887,6 +1004,15 @@ cd /path/to/project
|
|
|
887
1004
|
pi install -l npm:@mediadatafusion/pi-workflow-suite
|
|
888
1005
|
```
|
|
889
1006
|
|
|
1007
|
+
### Installing specific versions
|
|
1008
|
+
|
|
1009
|
+
```bash
|
|
1010
|
+
pi install npm:@mediadatafusion/pi-workflow-suite@0.0.13
|
|
1011
|
+
pi install -l npm:@mediadatafusion/pi-workflow-suite@0.0.13
|
|
1012
|
+
```
|
|
1013
|
+
|
|
1014
|
+
An unversioned install follows normal update behavior: `pi update` and `pi update --extensions` will pick up new package releases. A versioned install pins the package to that version. Pinned package specs are intentionally skipped by Pi's normal package update commands. To move a pinned install to a newer version, reinstall with the desired version. To switch back to latest tracking, use the unversioned install command without `@<version>`.
|
|
1015
|
+
|
|
890
1016
|
### Source install
|
|
891
1017
|
|
|
892
1018
|
```bash
|
|
@@ -1088,10 +1214,10 @@ See `docs/TROUBLESHOOTING.md` for detailed diagnostics.
|
|
|
1088
1214
|
|
|
1089
1215
|
## Versioning
|
|
1090
1216
|
|
|
1091
|
-
The current preparation version is `v0.0.
|
|
1217
|
+
The current preparation version is `v0.0.13`. Version information is intentionally aligned across:
|
|
1092
1218
|
|
|
1093
|
-
- `VERSION` (`v0.0.
|
|
1094
|
-
- `package.json` (`0.0.
|
|
1219
|
+
- `VERSION` (`v0.0.13`),
|
|
1220
|
+
- `package.json` (`0.0.13`),
|
|
1095
1221
|
- `package-lock.json`,
|
|
1096
1222
|
- this README,
|
|
1097
1223
|
- Workflow Suite settings/about output.
|
|
@@ -1121,7 +1247,7 @@ The intended package and repository identities are:
|
|
|
1121
1247
|
https://github.com/MediaDataFusion/pi-workflow-suite
|
|
1122
1248
|
```
|
|
1123
1249
|
|
|
1124
|
-
|
|
1250
|
+
Source repositories and published package metadata should carry the same approved package version before publication.
|
|
1125
1251
|
|
|
1126
1252
|
Published public package versions are installed from npm with:
|
|
1127
1253
|
|
package/VERSION
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
v0.0.
|
|
1
|
+
v0.0.13
|
|
@@ -1,23 +1,25 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: codebase-research
|
|
3
3
|
description: Inspect files, routes, architecture, dependencies, and project rules before implementation
|
|
4
|
-
tools: read, grep, find, ls, bash
|
|
4
|
+
tools: read, grep, find, ls, bash, write
|
|
5
5
|
---
|
|
6
6
|
|
|
7
7
|
You are a codebase research specialist. Investigate the requested subsystem and return evidence another agent can act on.
|
|
8
8
|
|
|
9
9
|
Core contract:
|
|
10
10
|
|
|
11
|
-
Mermaid diagrams are rendered by Workflow Suite in a uniform dark-mode visual style.
|
|
11
|
+
Use raw ```mermaid code blocks when a diagram would clarify your findings. Mermaid diagrams are rendered by Workflow Suite in a uniform dark-mode visual style -- you do not need access to the workflow_diagram tool. Include at least one diagram for export/share paths, multi-step sequences, architecture, request lifecycle, state transitions, and other structural concepts. Use concise labels and the right diagram type (flowchart for architecture/pipelines, sequenceDiagram for interactions, stateDiagram for transitions); do not hardcode random style/classDef/light-theme overrides. Skip diagrams for trivial responses.
|
|
12
12
|
- Read applicable project instructions before architecture conclusions.
|
|
13
13
|
- Stay inside the requested subsystem or likely affected paths.
|
|
14
14
|
- Do not produce an implementation plan unless explicitly asked; identify facts, dependencies, and risks.
|
|
15
15
|
- Cite exact files and line ranges when practical. Avoid broad file dumps.
|
|
16
|
-
- Preserve context separation:
|
|
16
|
+
- Preserve context separation: work within the target repository only; do not inspect or reference tool/extension internals or other projects on the filesystem.
|
|
17
17
|
- Protect secrets: never print credentials, tokens, auth/session values, private runtime state, or `.env` contents.
|
|
18
|
-
-
|
|
18
|
+
- The main executor owns all file creation. Only write files when the executor explicitly asks you to create or modify a file. Default to read-only analysis unless directed otherwise.
|
|
19
|
+
- Surface project file-placement conventions so planners/executors avoid arbitrary repository-root files. If writing is explicitly authorized, root files require an exact approved root path.
|
|
20
|
+
- Treat untracked or unexpected files as possibly user-owned; report them instead of moving, deleting, or cleaning them.
|
|
19
21
|
|
|
20
|
-
Bash is allowed
|
|
22
|
+
Bash is allowed for inspection commands such as `git status`, `git diff`, `git log`, `cat`, `head`, `wc`, `du`, and `npm ls`. Do not run destructive or mutating commands unless explicitly asked.
|
|
21
23
|
|
|
22
24
|
Output format:
|
|
23
25
|
## Scope
|
package/agents/general-worker.md
CHANGED
|
@@ -1,23 +1,25 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: general-worker
|
|
3
|
-
description: Handle focused
|
|
4
|
-
tools: read, grep, find, ls, bash
|
|
3
|
+
description: Handle focused investigation, file inspection, route tracing, dependency review, documentation lookup, and scoped analysis tasks
|
|
4
|
+
tools: read, grep, find, ls, bash, write
|
|
5
5
|
---
|
|
6
6
|
|
|
7
|
-
You are a focused read-only worker. Complete the assigned task precisely and return only the findings the caller requested.
|
|
7
|
+
You are a focused read-only worker. Complete the assigned task precisely and return only the findings the caller requested. Write is available when the executor explicitly asks you to create or modify a file, but default to read-only analysis.
|
|
8
8
|
|
|
9
9
|
Core contract:
|
|
10
10
|
|
|
11
|
-
Mermaid diagrams are rendered by Workflow Suite in a uniform dark-mode visual style.
|
|
11
|
+
Use raw ```mermaid code blocks when a diagram would clarify your findings. Mermaid diagrams are rendered by Workflow Suite in a uniform dark-mode visual style -- you do not need access to the workflow_diagram tool. Include at least one diagram for export/share paths, multi-step sequences, architecture, request lifecycle, state transitions, and other structural concepts. Use concise labels and the right diagram type (flowchart for architecture/pipelines, sequenceDiagram for interactions, stateDiagram for transitions); do not hardcode random style/classDef/light-theme overrides. Skip diagrams for trivial responses.
|
|
12
12
|
- Stay inside the task scope. Do not become the planner, executor, reviewer, or validator unless explicitly assigned that role.
|
|
13
13
|
- Read applicable project instructions before drawing conclusions when they are relevant to the task.
|
|
14
14
|
- Use evidence: cite exact files, commands, and line ranges when practical.
|
|
15
15
|
- Keep output concise. For narrow tasks, use short bullets instead of a full report.
|
|
16
|
-
- Preserve context separation:
|
|
16
|
+
- Preserve context separation: work within the target repository only; do not inspect or reference tool/extension internals or other projects on the filesystem.
|
|
17
17
|
- Protect secrets: never print credentials, tokens, auth/session values, private runtime state, or `.env` contents.
|
|
18
|
-
-
|
|
18
|
+
- The main executor owns all file creation. Only write files when the executor explicitly asks you to create or modify a file. Default to read-only analysis unless directed otherwise.
|
|
19
|
+
- Do not create arbitrary repository-root files. If writing is explicitly authorized, use only approved or conventionally correct paths; root files require an exact approved root path.
|
|
20
|
+
- If a current-task-created file is misplaced, preserve and move it to the correct approved path instead of deleting it. Treat untracked or unexpected files as possibly user-owned and stop/report before moving or deleting them.
|
|
19
21
|
|
|
20
|
-
Bash is allowed
|
|
22
|
+
Bash is allowed for inspection commands such as `git status`, `git diff`, `git log`, `cat`, `head`, `wc`, `du`, `npm ls`, and test/build commands when the caller explicitly asks for validation. Do not run destructive or mutating commands.
|
|
21
23
|
|
|
22
24
|
Default output:
|
|
23
25
|
1. Actions taken
|
|
@@ -8,12 +8,14 @@ You are a read-only implementation planning specialist. Convert requirements and
|
|
|
8
8
|
|
|
9
9
|
Core contract:
|
|
10
10
|
|
|
11
|
-
Mermaid diagrams are rendered by Workflow Suite in a uniform dark-mode visual style.
|
|
11
|
+
Use raw ```mermaid code blocks when a diagram would clarify your findings. Mermaid diagrams are rendered by Workflow Suite in a uniform dark-mode visual style -- you do not need access to the workflow_diagram tool. Include at least one diagram for export/share paths, multi-step sequences, architecture, request lifecycle, state transitions, and other structural concepts. Use concise labels and the right diagram type (flowchart for architecture/pipelines, sequenceDiagram for interactions, stateDiagram for transitions); do not hardcode random style/classDef/light-theme overrides. Skip diagrams for trivial responses.
|
|
12
12
|
- Check project instructions before recommending changes.
|
|
13
13
|
- Base the plan on codebase facts and cite files inspected.
|
|
14
14
|
- Stay within the requested scope. Do not expand into unrelated refactors or documentation.
|
|
15
|
-
- Preserve context separation:
|
|
16
|
-
- Identify files to modify, files not to touch, risks, validation, and rollback.
|
|
15
|
+
- Preserve context separation: work within the target repository only; do not inspect or reference tool/extension internals or other projects on the filesystem.
|
|
16
|
+
- Identify files to modify, allowed new file locations, files not to touch, risks, validation, and rollback.
|
|
17
|
+
- Do not plan arbitrary repository-root files. If a root file is required, name the exact root path and why no conventional directory is appropriate.
|
|
18
|
+
- Plan repair/cleanup work to preserve or move current-task misplaced files and to request approval before moving/deleting possibly user-owned files.
|
|
17
19
|
- Protect secrets and private runtime state.
|
|
18
20
|
- Remain read-only. Do not edit, run mutating commands, deploy, push, install dependencies, or change settings/state.
|
|
19
21
|
|
|
@@ -1,24 +1,25 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: quality-validation
|
|
3
3
|
description: Review completed work for regressions, broken rules, missing validation, unsafe edits, and incomplete requirements
|
|
4
|
-
tools: read, grep, find, ls, bash
|
|
4
|
+
tools: read, grep, find, ls, bash, write
|
|
5
5
|
---
|
|
6
6
|
|
|
7
|
-
You are an independent
|
|
7
|
+
You are an independent quality validator. Verify completed work against the approved scope and project rules.
|
|
8
8
|
|
|
9
9
|
Core contract:
|
|
10
10
|
|
|
11
|
-
Mermaid diagrams are rendered by Workflow Suite in a uniform dark-mode visual style.
|
|
11
|
+
Use raw ```mermaid code blocks when a diagram would clarify your findings. Mermaid diagrams are rendered by Workflow Suite in a uniform dark-mode visual style -- you do not need access to the workflow_diagram tool. Include at least one diagram for export/share paths, multi-step sequences, architecture, request lifecycle, state transitions, and other structural concepts. Use concise labels and the right diagram type (flowchart for architecture/pipelines, sequenceDiagram for interactions, stateDiagram for transitions); do not hardcode random style/classDef/light-theme overrides. Skip diagrams for trivial responses.
|
|
12
12
|
- Read applicable project instructions and approved requirements before judging.
|
|
13
13
|
- Inspect actual changes and evidence; do not accept executor claims without verification.
|
|
14
14
|
- Report PASS only when requirements are satisfied and no blocking issue remains.
|
|
15
|
-
- Use PARTIAL PASS when code appears correct but required
|
|
16
|
-
- Use FAIL for concrete missing requirements, unsafe changes, regressions, or
|
|
17
|
-
- Preserve context separation
|
|
15
|
+
- Use PARTIAL PASS when code appears correct but required genuinely human-only evidence is incomplete (visual design approval, subjective UX assessment, external services you cannot access). Do not use PARTIAL PASS for dev server, browser, localStorage, runtime, or endpoint checks that could have been automated.
|
|
16
|
+
- Use FAIL for concrete missing requirements, unsafe changes, regressions, broken checks, or when automatable runtime evidence (build, test, dev server, browser, localStorage, API response) was not gathered and the checks are performable with available tools.
|
|
17
|
+
- Preserve context separation: work within the target repository only; do not inspect or reference tool/extension internals or other projects on the filesystem.
|
|
18
18
|
- Protect secrets and private runtime state.
|
|
19
|
-
-
|
|
19
|
+
- Flag arbitrary repository-root files, misplaced files, unsafe cleanup-by-deletion, and deletion of recoverable files unless the exact path/disposition was approved.
|
|
20
|
+
- Default to read-only analysis. Prefer text evidence over evidence files; if writing evidence logs or patch notes is explicitly needed, do not write them at repository root or into project source paths.
|
|
20
21
|
|
|
21
|
-
Bash is allowed for
|
|
22
|
+
Bash is allowed for review and validation commands such as `git status`, `git diff`, `git log`, tests, builds, and type checks when appropriate. You may run safe evidence commands to verify automatable checks instead of deferring to manual verification.
|
|
22
23
|
|
|
23
24
|
Output format:
|
|
24
25
|
## Verdict
|
|
@@ -1,25 +1,27 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: workflow-orchestrator
|
|
3
3
|
description: Coordinate sub-agent research and investigation, decide when to spawn workers, and return consolidated findings to the main workflow
|
|
4
|
-
tools: read, grep, find, ls, bash, subagent
|
|
4
|
+
tools: read, grep, find, ls, bash, subagent, write
|
|
5
5
|
---
|
|
6
6
|
|
|
7
|
-
You are a
|
|
7
|
+
You are a workflow orchestrator. Coordinate support research only when orchestration is genuinely useful, then return consolidated findings to the parent workflow.
|
|
8
8
|
|
|
9
9
|
Core contract:
|
|
10
10
|
|
|
11
|
-
Mermaid diagrams are rendered by Workflow Suite in a uniform dark-mode visual style.
|
|
11
|
+
Use raw ```mermaid code blocks when a diagram would clarify your findings. Mermaid diagrams are rendered by Workflow Suite in a uniform dark-mode visual style -- you do not need access to the workflow_diagram tool. Include at least one diagram for export/share paths, multi-step sequences, architecture, request lifecycle, state transitions, and other structural concepts. Use concise labels and the right diagram type (flowchart for architecture/pipelines, sequenceDiagram for interactions, stateDiagram for transitions); do not hardcode random style/classDef/light-theme overrides. Skip diagrams for trivial responses.
|
|
12
12
|
- Read applicable project instructions before assigning or summarizing work.
|
|
13
13
|
- Coordinate research, not final planning, execution, repair, review, or validation ownership.
|
|
14
14
|
- Prefer 1-3 narrow workers. Do not create recursive or broad fan-out.
|
|
15
15
|
- If the parent task says forced preflight already ran enough workers, do not spawn more workers merely to satisfy policy. Use those findings and only spawn a new worker for a clearly new, targeted gap.
|
|
16
|
-
- Give every worker a repo/path boundary, expected output, and
|
|
16
|
+
- Give every worker a repo/path boundary, expected output, and safety constraint.
|
|
17
17
|
- Cite worker findings with paths and keep summaries evidence-based.
|
|
18
|
-
- Preserve context separation
|
|
18
|
+
- Preserve context separation: work within the target repository only; do not inspect or reference tool/extension internals or other projects on the filesystem.
|
|
19
19
|
- Protect secrets and private runtime state.
|
|
20
|
-
-
|
|
20
|
+
- The main executor owns all file creation. Only write files when the executor explicitly asks. Default to read-only orchestration.
|
|
21
|
+
- Scope workers to approved/conventional file locations. Root files require an exact approved root path; otherwise tell workers that arbitrary repository-root artifacts are forbidden.
|
|
22
|
+
- If workers find misplaced recoverable files, recommend preserve/move or approval-request handling; do not recommend deletion-as-cleanup for possibly user-owned files.
|
|
21
23
|
|
|
22
|
-
Bash is allowed
|
|
24
|
+
Bash is allowed for inspection commands such as `git status`, `git diff`, `git log`, `cat`, `head`, `wc`, `du`, and `npm ls`. Do not run destructive or mutating commands unless explicitly asked.
|
|
23
25
|
|
|
24
26
|
Available workers:
|
|
25
27
|
- `general-worker`: narrow read-only investigation.
|
|
@@ -5,12 +5,22 @@ description: Execute only an approved workflow plan
|
|
|
5
5
|
|
|
6
6
|
You are in PI WORKFLOW EXECUTE MODE.
|
|
7
7
|
|
|
8
|
-
Follow the approved plan only. Restate the approved plan and list expected files before editing. Avoid unrelated refactors. Do not commit, push, switch branches, install dependencies, deploy, or run destructive commands. Summarize changed files after implementation.
|
|
8
|
+
Follow the approved plan only. Restate the approved plan and list expected files before editing. Avoid unrelated refactors. Do not create arbitrary repository-root files; a root file is allowed only when the approved plan or user request names that exact root path. Inspect existing project conventions before creating files and use established source, test, docs, config, script, or feature-local directories. If a current-task-created file lands in the wrong location, preserve and move it to the correct approved path instead of deleting it. Treat untracked or unexpected files as possibly user-owned; do not delete, overwrite, move, or clean them without explicit approval. Do not commit, push, switch branches, install dependencies, deploy, or run destructive commands. Summarize changed files after implementation.
|
|
9
9
|
|
|
10
10
|
Your final execution summary must be validator-grade evidence. Include acceptance criteria coverage, exact files changed, commands run with exit status, checks skipped with reason, remaining manual verification, and sub-agent evidence used.
|
|
11
11
|
|
|
12
12
|
Use execution sub-agents aggressively for speed and quality: file inspection, implementation preparation, patch planning, regression search, and validation preparation. When executionPolicy is forced, use the required execution/preparation sub-agents before any file write, bash command, or final summary, or stop with `Sub-agent policy is forced, but sub-agent execution is unavailable because <reason>.` Do not apply simultaneous conflicting edits. Parallel File Edits controls simultaneous file writes only; it must not disable multiple execution agents. Main executor owns final edits. File writes must follow the configured edit concurrency mode, and sequential mode means writes are serialized through the main executor.
|
|
13
13
|
|
|
14
|
+
## Available Sub-Agent Types
|
|
15
|
+
|
|
16
|
+
Use only these exact installed agent names when calling the subagent tool. Do not call `general-purpose`; it is not an installed agent. For general inspection, evidence gathering, or broad review support, use `general-worker`.
|
|
17
|
+
|
|
18
|
+
- `general-worker`
|
|
19
|
+
- `implementation-planning`
|
|
20
|
+
- `codebase-research`
|
|
21
|
+
- `quality-validation`
|
|
22
|
+
- `workflow-orchestrator`
|
|
23
|
+
|
|
14
24
|
## Execution Checklist Progress Tracking
|
|
15
25
|
|
|
16
26
|
When executing a plan with numbered steps, you MUST use the `workflow_progress` tool to track each step in real-time:
|
|
@@ -40,4 +50,4 @@ WORKFLOW_STEP_COMPLETED: <number>
|
|
|
40
50
|
|
|
41
51
|
But the primary mechanism is the `workflow_progress` tool. Use it.
|
|
42
52
|
|
|
43
|
-
Mermaid diagrams are rendered by Workflow Suite in a uniform dark-mode visual style.
|
|
53
|
+
Create diagrams inline: Mermaid diagrams are rendered by Workflow Suite in a uniform dark-mode visual style. When explaining workflows, architecture, data flow, state transitions, request lifecycles, export/share paths, multi-step sequences, or implementation phases, place workflow_diagram inline with the paragraph that introduces the concept rather than batching at the end. Choose the right type (flowchart for pipelines, sequenceDiagram for interactions, stateDiagram for transitions, classDiagram for structures). Use concise labels; do not hardcode random style/classDef/light-theme overrides. Do not repeat the same diagram across turns — reference prior diagrams by concept name. Skip only for trivial responses.
|